TEP: SBT Standard #85

xssnick · 2022-09-01T11:05:47Z

Soul bound token (SBT) is a special kind of NFT which can be transferred only between its owner's accounts. For this, it stores immutable public key of the owner, and it is needed to send transfer from new address with signature in payload to change owner's address.

There is a useful type of token which allows to give social permissions/roles or certificates to some users. For example, it can be used by marketplaces to give discounts to owners of SBT, or by universities to give attestation certificates in SBT form. Mechanics with ownership proof allows to easily prove to any contract that you are an owner of some SBT.

SBT implements NFT standard interface but transfer should always be rejected, pull_ownership is used instead.

text/0083-sbt-standard.md

EmelyanenkoK · 2022-09-02T12:19:46Z

text/0083-sbt-standard.md

+
+In case when `verify_ownership` was bounced back to SBT, SBT should send message to owner with schema:
+```
+verify_ownership_bounced#81b510c2 query_id:uint64 sbt_id:uint256 owner:MsgAddress 


Does owner need sbt_id, owner, data and content in this case?

It is like proxy of bounced message, technically i think most of that it is not so useful, but just for similarity with original.

As a use case, sbt_id can be used to confirm that bounce was from real SBT, by calculating address and comparing with sender.

EmelyanenkoK · 2022-09-02T12:21:14Z

text/0083-sbt-standard.md

+Sender address is not an owner's address.
+
+**Otherwise should do:**
+Set owner's address to null and set public key to 0.


Do we need response with excess money here back to owner?
Do we want to keep enough balance on SBT to ensure it will not be frozen and destroyed for a long time?

Good suggestion, I think we can add reserve of 0.05 TON and return excess back, if balance is less than 0.05 throw an error. Do you think it is good approach?

EmelyanenkoK · 2022-09-02T12:22:46Z

text/0083-sbt-standard.md

+1. `get_public_key()` - returns `int`, that is owner's public key.
+2. `get_nonce()` - returns `int`, which current nonce.
+3. `get_nft_data()` - same as in [NFT standard](https://github.com/ton-blockchain/TIPs/issues/62).
+4. `get_authority_address()` - returns `slice`, that is authority's address. Authority can revoke SBT.


If authority can not be changed may be it is better to force collection to be authority? Not sure though

Then it will require custom collection to work with SBT, with additional revoke method, not sure if it will be good.

text/0083-sbt-standard.md

hacker-volodya · 2022-09-05T16:25:00Z

"Drawbacks" section is missing.

Added initiator address to verify_onwership

xssnick · 2022-09-06T07:02:53Z

"Drawbacks" section is missing.

Added

oleganza · 2022-09-12T13:55:44Z

text/0083-sbt-standard.md

+
+`sbt_nonce` - nonce, required for protection of signature replay attacks.
+
+`new_owner` - address of the new owner of the SBT item, should be the same as sender's address.


Why don't we use sender's address directly, without duplicating it in the message?

In your case, imagine situation when we have quite sharded chain and new owner from shard 0b00000 try to pull_ownership from sbt deployed in 0b11111. Message from new owner will migrate to new address some time during which attacker from the same shard may be able to send exactly the same message (signature will be valid since it doesn't include anything specific to new owner) and get sbt. While it is not critical (ownership is still bound to the public key, not the address), it is bad enough to avoid such attacks.

Could you clarify what does "address of the new owner [...] should be the same as sender's address" mean? If we need to deal with sharding in some specific way, shouldn't we put this into spec?

pull_ownership request should cover by signature the same address from which request came. Yes, in theory, we may not include sender address into the request and instead construct signed body from request payload and sender address. However in practice it is much simpler to explicitly provide payload which was signed.

Ok, i see, this makes signature verification simpler this way. In principle, we should weigh the cost of transmitting extra 32 bytes vs gas spent constructing a cell for signature, but i doubt those extra 32 bytes would make a noticeable difference.

oleganza · 2022-09-12T16:23:12Z

I looked at the spec, I have a few cosmetic suggestions:

1. Owner & Wallet

Let's use consistent naming for owner and wallet. The SBT is designed to be bound to the owner, but leaves ability to switch the wallet in case the owner upgrades from v3 to v4 or to v5, while keeping the same private key inside.

Rename pubkey method to clarify the role of the pubkey:

owner field
get_public_key() -> get_owner_key()

Rename "pull ownership" because it sounds like some authority is taking away your ownership. We use it to switch the wallet, but keep the same owner.

pull_ownership(... new_owner: ...) -> switch_wallet(... new_wallet: ...)

2. Nonce vs Seqno

Seems like doing seqno+=1 like in the wallet code is the simplest replay protection possible, so maybe we should rename nonce into seqno.

3. Unify revoke & destroy?

Maybe the spec could be made simpler if we unify revoke and destroy as one method destroy. If we want to tag things in the explorer or API, we could simply check if the msg sender is the SBT's wallet or the authority and mark the transaction accordingly.

oleganza · 2022-09-12T16:27:45Z

From the UX perspective the SBT always belongs to the wallet, so switch_wallet method (currently pull_ownership) is going to be used within some migration flow, not as a general purpose "transfer" UI. This also means that the wallet is not concerned with transferring the privkey of SBT to any other location and securing it along the way.

xssnick · 2022-09-12T17:59:38Z

I looked at the spec, I have a few cosmetic suggestions:

1. Owner & Wallet

Let's use consistent naming for owner and wallet. The SBT is designed to be bound to the owner, but leaves ability to switch the wallet in case the owner upgrades from v3 to v4 or to v5, while keeping the same private key inside.

Rename pubkey method to clarify the role of the pubkey:

owner field get_public_key() -> get_owner_key()

Rename "pull ownership" because it sounds like some authority is taking away your ownership. We use it to switch the wallet, but keep the same owner.

pull_ownership(... new_owner: ...) -> switch_wallet(... new_wallet: ...)

2. Nonce vs Seqno

Seems like doing seqno+=1 like in the wallet code is the simplest replay protection possible, so maybe we should rename nonce into seqno.

3. Unify revoke & destroy?

Maybe the spec could be made simpler if we unify revoke and destroy as one method destroy. If we want to tag things in the explorer or API, we could simply check if the msg sender is the SBT's wallet or the authority and mark the transaction accordingly.

Yea, agreed with switch_wallet, it looks better, will update. But not sure about changing get_public_key to get_owner_key, because currently interface is same with wallet’s method, it allows to universally get the owner’s key of both entities.
Nonce was used here because with seqno we have a low chance of replay attack, if 2 sbts of the same owner of same collection are connected to one key. If seqno is same, attacker can repeat the request on second sbt and change wallet address to same as on first one. It is not so critical, since it is very rare case, but nonce resolves it and looks better here.
I think revoke and destroy are different processes and in some cases they can contain additional logic, so imo it is better to keep them as separate operations.

oleganza · 2022-09-12T19:07:47Z

Another note: conceptually, we need to put as little logic in the contract as possible to enforce relationship between the designated parties. In our case the parties are: "the owner" (identified by a fixed pubkey) and "the authority" (maybe rename this to "issuer"?).

Do we really need a concept of a "wallet" here at all? If we don't then:

We do not need to have switch_wallet logic at all. When user migrates the wallet from v5 to v7 nothing has to happen to SBP. We can move that signature verification into the prove_ownership method instead.
Wallets need to have a special support for SBTs anyway (to prove ownership and display them distinctly from NFTs because SBTs can't be transferred, to support token-specific features), so they might as well pick them up by the pubkey instead of the NFT ownership API.

NFTItem interface is cool because you control that thing with an arbitrary address (which could be plain wallet, multisig, etc.), but SBT is not really controlled by the wallet, but explicitly controlled by a fixed pubkey.

oleganza · 2022-09-13T20:55:45Z

text/0083-sbt-standard.md

+TL-B schema of inbound message:
+```
+prove_ownership#04ded148 query_id:uint64 dest:MsgAddress 
+forward_payload:^Cell with_content:Bool = InternalMsgBody;


Suggested change

forward_payload:^Cell with_content:Bool = InternalMsgBody;

data:^Cell with_content:Bool = InternalMsgBody;

?

oleganza · 2022-09-13T20:56:33Z

text/0083-sbt-standard.md

+
+TL-B schema of inbound message:
+```
+pull_ownership#08496845 query_id:uint64 signature:^(bits 512) 


why query_id goes before the signature? Shouldn't it be covered by the signature and it'd be easier to verify it if sig comes first?

xssnick · 2022-09-18T07:09:47Z

After additional discussions standard was split to this one and NFT Ownership, and simplified.

Implementation and description was changed.

oleganza · 2022-09-19T12:16:17Z

I am pretty happy with the concept of making SBT a ≈subset of NFTs. The definition "SBT = NFT where only the minter/issuer/authority can transfer" seems like the minimal possible one. From the perspective of the ecosystem that's enough.

But for the security of the issuer they need to verify that the recipient's wallet is a regular wallet v3/v4 so they don't accidentally issue SBT to a transferrable "holding contract" that would effectively "wrap" SBT into a transferrable NFT and hamper the bonding property.

EmelyanenkoK · 2022-09-29T12:20:44Z

LGTM

dvlkv

LGTM.

tvorogme · 2022-09-30T13:16:08Z

Great work, LGTM

hacker-volodya · 2022-10-01T15:28:15Z

This TEP enters its Final Comment Period. It ends in 10 calendar days, 11.10.2022.

DeFiTON · 2022-10-01T15:33:37Z

LGTM

hacker-volodya · 2022-10-11T14:25:08Z

The Final Comment Period is complete with a disposition to merge. Thanks to the authors of TEP, @xssnick, @Naltox, @EmelyanenkoK, @oleganza, and to all who took part in the discussion. This pull request will be merged now.

SBT Standard

c4cf24b

EmelyanenkoK reviewed Sep 1, 2022

View reviewed changes

text/0083-sbt-standard.md Outdated Show resolved Hide resolved

EmelyanenkoK reviewed Sep 1, 2022

View reviewed changes

text/0083-sbt-standard.md Outdated Show resolved Hide resolved

EmelyanenkoK reviewed Sep 1, 2022

View reviewed changes

text/0083-sbt-standard.md Outdated Show resolved Hide resolved

xssnick added 2 commits September 1, 2022 16:06

Update 0083-sbt-standard.md

ef47eea

Recalculated checksums for SBT messages

4b6b240

xssnick changed the title ~~SBT Standard~~ TEP: SBT Standard Sep 1, 2022

EmelyanenkoK reviewed Sep 2, 2022

View reviewed changes

hacker-volodya reviewed Sep 5, 2022

View reviewed changes

text/0083-sbt-standard.md Outdated Show resolved Hide resolved

Update 0083-sbt-standard.md

af36056

Added initiator address to verify_onwership

xssnick added 2 commits September 6, 2022 18:52

Update 0083-sbt-standard.md

791bd39

Update 0083-sbt-standard.md

08024ea

oleganza reviewed Sep 12, 2022

View reviewed changes

Hiyorimi mentioned this pull request Sep 13, 2022

PR closes #31 ton-society/grants-and-bounties#39

Merged

oleganza reviewed Sep 13, 2022

View reviewed changes

xssnick added 2 commits September 16, 2022 16:52

Update 0083-sbt-standard.md

1472bdd

Update 0083-sbt-standard.md

60f00b3

xssnick added 2 commits September 28, 2022 16:59

Updated SBT standard

b8573c6

Update 0083-sbt-standard.md

38f2693

xssnick added 3 commits September 28, 2022 17:24

Update 0083-sbt-standard.md

7e4eb4d

Update 0083-sbt-standard.md

2b75520

Update 0083-sbt-standard.md

9217eda

Naltox approved these changes Sep 28, 2022

View reviewed changes

dvlkv approved these changes Sep 30, 2022

View reviewed changes

TrueCarry approved these changes Sep 30, 2022

View reviewed changes

hacker-volodya added the FCP label Oct 1, 2022

Update 0083-sbt-standard.md

043165a

hacker-volodya merged commit 54cf21c into ton-blockchain:master Oct 11, 2022

Naltox mentioned this pull request Nov 1, 2022

Develop a universally adopted wrapped Toncoin (wTON) ton-society/grants-and-bounties#64

Closed

MrG9090 approved these changes Nov 29, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

TEP: SBT Standard #85

TEP: SBT Standard #85

xssnick commented Sep 1, 2022

EmelyanenkoK Sep 2, 2022

xssnick Sep 2, 2022

EmelyanenkoK Sep 2, 2022

xssnick Sep 2, 2022

xssnick Sep 6, 2022

EmelyanenkoK Sep 2, 2022

xssnick Sep 2, 2022

hacker-volodya commented Sep 5, 2022

xssnick commented Sep 6, 2022

oleganza Sep 12, 2022

EmelyanenkoK Sep 12, 2022

oleganza Sep 12, 2022

EmelyanenkoK Sep 12, 2022

oleganza Sep 12, 2022

oleganza commented Sep 12, 2022

oleganza commented Sep 12, 2022

xssnick commented Sep 12, 2022

1. Owner & Wallet

2. Nonce vs Seqno

3. Unify revoke & destroy?

oleganza commented Sep 12, 2022

oleganza Sep 13, 2022

oleganza Sep 13, 2022 •

edited

Loading

xssnick commented Sep 18, 2022

oleganza commented Sep 19, 2022

EmelyanenkoK commented Sep 29, 2022

dvlkv left a comment

tvorogme commented Sep 30, 2022

hacker-volodya commented Oct 1, 2022

DeFiTON commented Oct 1, 2022

hacker-volodya commented Oct 11, 2022


		`sbt_nonce` - nonce, required for protection of signature replay attacks.

		`new_owner` - address of the new owner of the SBT item, should be the same as sender's address.

	forward_payload:^Cell with_content:Bool = InternalMsgBody;
	data:^Cell with_content:Bool = InternalMsgBody;

TEP: SBT Standard #85

TEP: SBT Standard #85

Conversation

xssnick commented Sep 1, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hacker-volodya commented Sep 5, 2022

xssnick commented Sep 6, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

oleganza commented Sep 12, 2022

1. Owner & Wallet

2. Nonce vs Seqno

3. Unify revoke & destroy?

oleganza commented Sep 12, 2022

xssnick commented Sep 12, 2022

1. Owner & Wallet

2. Nonce vs Seqno

3. Unify revoke & destroy?

oleganza commented Sep 12, 2022

Choose a reason for hiding this comment

oleganza Sep 13, 2022 • edited Loading

Choose a reason for hiding this comment

xssnick commented Sep 18, 2022

oleganza commented Sep 19, 2022

EmelyanenkoK commented Sep 29, 2022

dvlkv left a comment

Choose a reason for hiding this comment

tvorogme commented Sep 30, 2022

hacker-volodya commented Oct 1, 2022

DeFiTON commented Oct 1, 2022

hacker-volodya commented Oct 11, 2022

oleganza Sep 13, 2022 •

edited

Loading